Android Camera

您所在的位置:网站首页 evs APP 摄像头 Android Camera

Android Camera

2024-07-13 13:05| 来源: 网络整理| 查看: 265

一、Android Camera介绍

Android的Camera系统包括手机的Camera系统(Camera2)和车机的Camera系统(EVS:exterior view system),

车载和手机的Camera系统是两套不一样的架构,手机Camera系统最终生成符合人眼感官的图像,需要考虑多样化的场景,如美颜、夜景提亮、降噪、虚化等;而车载Camera系统AIS(Automotive Imaging System)的图像大部分是给自动驾驶等机器识别使用,更多考虑的是远距离传输、多摄像头图像处理等场景。因此两套系统不管是从硬件结构还是从软件框架上差异都很大。下面分别进行介绍:

手机Camera

手机Camera通常采用Camera2,整体架构如下:

从上图得知,Android手机中Camera软件主要有大体上有4层:

应用层: 应用开发者调用AOSP提供的接口即可,AOSP的接口即Android提供的相机应用的通用接口,这些接口将通过Binder与Framework层的相机服务进行操作与数据传递;

Framework层: 位于 frameworks/av/services/camera/libcameraservice/CameraService.cpp ,相机Framework服务是承上启下的作用,上与应用交互,下与HAL曾交互。

Hal层: 硬件抽象层,Android 定义好了Framework服务与HAL层通信的协议及接口,HAL层如何实现有各个Vendor自己实现,如Qcom的老架构mm-Camera,新架构Camx架构,Mtk的P之后的Hal3架构.

Driver层: 驱动层,数据由硬件到驱动层处理,驱动层接收HAL层数据以及传递Sensor数据给到HAL层,这里当然是各个Sensor芯片不同驱动也不同.

Android要适应各个手机组装厂商的不同配置,不同sensor,不管怎么换芯片,从Framework及之上都不需要改变,App也不需要改变就可以在各种配置机器上顺利运行,HAL层对上的接口也由Android定义死,各个平台厂商只需要按照接口实现适合自己平台的HAL层即可.

Camera2工作大体流程:

绿色框中是应用开发者需要做的操作,蓝色为AOSP提供的API,黄色为Native Framework Service,紫色为HAL层Service.

描述一下步骤:

App一般在MainActivity中使用SurfaceView或者SurfaceTexture+TextureView或者GLSurfaceView等控件作为显示预览界面的控件,共同点都是包含了一个单独的Surface作为取相机数据的容器.

在MainActivity onCreate的时候调用API 去通知Framework Native Service CameraServer去connect HAL继而打开Camera硬件sensor.

openCamera成功会有回调从CameraServer通知到App,在onOpenedCamera或类似回调中去调用类似startPreview的操作.此时会创建CameraCaptureSession,创建过程中会向CameraServer调用ConfigureStream的操作,ConfigureStream的参数中包含了第一步中空间中的Surface的引用,相当于App将Surface容器给到了CameraServer,CameraServer包装了下该Surface容器为stream,通过HIDL传递给HAL,继而HAL也做configureStream操作。

ConfigureStream成功后CameraServer会给App回调通知ConfigStream成功,接下来App便会调用AOSP setRepeatingRequest接口给到CameraServer,在Camera3Device初始化时起来了一个死循环线程 RequestThread来接收Request。

CameraServer将request交到Hal层去处理,得到HAL处理结果后取出该Request的处理Result中的Buffer填到App给到的容器中,SetRepeatingRequest为了预览,则交给Preview的Surface容器,如果是Capture Request则将收到的Buffer交给ImageReader的Surface容器.

Surface本质上是BufferQueue的使用者和封装者,当CameraServer中App设置来的Surface容器被填满了BufferQueue机制将会通知到应用,此时App中控件取出各自容器中的内容消费掉,Preview控件中的Surface中的内容将通过View提供到SurfaceFlinger中进行合成最终显示出来,即预览;而ImageReader中的Surface被App取出保存成图片文件消费掉.

比较简单的一张图:

车载Camera

  车载Camera的基本组成如下,黄色的箭头代表数据的传输,蓝色的箭头代表控制信号的传输。

ISP图像处理芯片有的会放置在摄像头这边,把处理后的信号传输给到主机,有的是不放置ISP芯片,由主机那边的内置ISP芯片进行图像处理,这样摄像头端的散热会好很多,辐射也小。

​ 这里跟手机Camera最大的差别是多了一个串行器和解串器。我们知道相机传感器或ISP的图像数据输出总线是MIPI CSI标准,其特点是高速穿行,但是传输总线距离较短,否则容易受到干扰无法保证信号的完整性,所以在车辆上,我们需要将其转换成例如GMSL等适合在车上长距离传输的高速总线标准进行传输,所以相机模组内部通常会通过串行板进行总线的转换。另外同轴电缆既可以用来为模组提供电源,也可以传输图像数据。如一些项目,串行器使用MAX92745,解串器是MAX9296A。

​ 总的来说,手机系统上,SOC对接camera硬件,可以直接操作摄像头;而车载系统上,SOC对接的是解串器,camera的配置、上下电需要摄像头模组内的串行器来控制,另外摄像头的供电和信号传输是通过同轴电缆完成的。

​ 车载Camera最经典的使用场景是360°全景图像系统(AVM:Around View Monitor),其硬件拓扑图如下。

原理是利用最少4个广角摄像头的数据合成一幅360°图像的画面。

​ 高清摄像头项目有2种配置方式,分为泊车摄像头(前、后、左、有)和倒车后视摄像头。泊车摄像头和倒车后视摄像头除了Lens其他硬件方案一样。

​ 泊车摄像头系统由安装于车身前、后、左、右四路高清摄像头和智能域控制器组成,域控制器通过同轴线(POC)给摄像头供电,摄像头经过LVDS串行器将视频信号传输给域控制器。摄像头进行图像采集,域控制器对图像进行裁剪、畸变校正、图像拼接、2D/3D视角切换、轨迹线生成等处理,XPU处理完后送入中央控制域进行显示。如下图高清全景系统连接示意图。

倒车后视摄像头系统由安装于车身后部高清摄像头和中央域控制器组成,摄像头进行图像采集,中央域控制器对图像进行裁减、轨迹线生成、显示屏显示等处理。如下图倒车后视摄像头系统连接示意图。

EVS

外部视图系统 (EVS:exterior view system) 通常用于在搭载基于 Android 的车载信息娱乐 (IVI) 系统的汽车上为后视摄像头和环绕视图显示提供支持。

EVS就是将相机获取的图像数据,快速传送到显示屏上,相比于传统的相机,有一下优势:

快速启动:EVS HAL的设计,使得camera到display的流程依赖最小化,内核一旦启动,显示也会随之启动,两者之间的传输时间较大减小;

可扩展性:EVS 提供了一种安全的方式,来让应用通过只读的方式,获取车载摄像机的反馈,这样应用端就可以由此实现 脸部识别,标志检测,路况报告等一些高级功能,具体见config.json。

可配置性:EVS 的HAL 层设计的要比完整的camera HAL 层简单,并且在客户端,通过config.json 对camera 进行配置, 并且google也提供了一些 demo,可以随意查看CameraName_Backup、LaneView、right turn 摄像头。

EVS的系统框架:

EVS 应用

可作为参考实现的 C++ EVS 示例应用 (\packages\services\Car\cpp\evs\apps)。该应用负责从 EVS 管理器请求视频帧,并将用于显示的已完成的帧发送回 EVS 管理器。EVS 和汽车服务可供使用后,它便立即由 init 启动(设置目标为在开机两 (2) 秒内启动)。原始设备制造商 (OEM) 可视需要修改或替换 EVS 应用。

EVS 管理器

EVS 管理器可提供 EVS 应用所需的构建块,以实现从简单的后视摄像头显示到 6DOF 多摄像头渲染的任何功能。它的接口通过 HIDL 呈现,并且能够接受多个并发客户端。其他应用和服务(特别是汽车服务)可以查询 EVS 管理器状态,以了解 EVS 系统何时处于活动状态。

EVS AIDL接口

在 EVS 系统中,相机和显示元素均由 android.hardware.automotive.evs 软件包定义。用于实践接口的示例实现(生成合成测试图像并验证图像进行往返的过程)在 \packages\services\Car\cpp\evs\manager中提供。

原始设备制造商 (OEM) 负责实现EVS AIDL API。这种实现负责从物理相机配置和收集数据,并通过 Gralloc 可识别的共享内存缓冲区传送这些数据。实现的显示端负责提供可由应用填充(通常通过 EGL 渲染的方式)的共享内存缓冲区,并优先呈现已完成的帧(在任何可能会显示在物理显示设备上的其他内容之前)。EVS 接口的供应商实现可以存储在 /vendor/… /device/… 或 hardware/…(例如 /hardware/[vendor]/[platform]/evs)下。

内核驱动程序

支持 EVS 堆栈的设备需要使用内核驱动程序。原始设备制造商 (OEM) 无需创建新驱动程序,他们可以选择通过现有相机和/或显示硬件驱动程序来支持 EVS 所需的功能。重复使用驱动程序可能会有好处,对于图像呈现可能需要与其他活动线程协调的显示驱动程序来说尤其如此。



【本文地址】


今日新闻


推荐新闻


CopyRight 2018-2019 办公设备维修网 版权所有 豫ICP备15022753号-3